Please address the comments from this code review:

## Overall Comments
- The `test_list_tasks_negative_pagination_safely_clamped` docstring describes potential future behavior (422 from Pydantic) that is not asserted in the test, which can become misleading over time; consider either removing the forward-looking note or encoding that expectation explicitly (e.g., via parametrization) when/if the behavior changes.
- Now that the module mixes HTTP-level tests (`py_api`) and direct function-call tests (`list_tasks` + `expdb_test`), consider grouping or naming the tests to make the separation of concerns clearer (e.g., split into separate files or use naming prefixes for API vs. direct-call tests).

## Individual Comments

### Comment 1
<location path="tests/routers/openml/task_list_test.py" line_range="241-244" />
<code_context>
+async def test_list_tasks_no_results(payload: dict[str, Any], expdb_test: AsyncConnection) -> None:
</code_context>
<issue_to_address>
**suggestion (testing):** Consider keeping an HTTP-level `py_api` test for 404 NoResultsError mapping in addition to the direct-call exception test.

The previous version validated the full HTTP behavior (404 status, `application/problem+json` content type, and inclusion of `NoResultsError.uri` in the body). The new version only confirms that `list_tasks` raises the correct Python exception, but not that it’s mapped to the expected HTTP response. Please either reintroduce an HTTP-level test (e.g. `test_list_tasks_no_results_http`) or add a small `py_api` test that asserts 404 + `problem+json` + error type, and keep this direct-call test as-is.

Suggested implementation:

```python
@pytest.mark.parametrize(
    "payload",
    [
        # A tag that does not exist
        {"tag": "nonexistent-tag-123"},
        # A task ID that does not exist
        {"task_id": 999999999},
        # A data_name that does not match any task
        {"data_name": "nonexistent-dataset-123"},
    ],
    ids=["bad_tag", "bad_task_id", "bad_data_name"],
)
async def test_list_tasks_no_results(payload: dict[str, Any], expdb_test: AsyncConnection) -> None:
    """Filters matching nothing raise NoResultsError at the Python API level."""
    # Direct-call test that ensures the router logic raises the domain exception.
    with pytest.raises(NoResultsError):
        await list_tasks(expdb_test, **payload)


@pytest.mark.parametrize(
    "payload",
    [
        {"tag": "nonexistent-tag-123"},
        {"task_id": 999999999},
        {"data_name": "nonexistent-dataset-123"},
    ],
    ids=["bad_tag", "bad_task_id", "bad_data_name"],
)
async def test_list_tasks_no_results_http(
    payload: dict[str, Any],
    async_client: AsyncClient,
) -> None:
    """Filters matching nothing are mapped to HTTP 404 problem+json with NoResultsError type."""
    response = await async_client.get("/openml/tasks", params=payload)

    assert response.status_code == status.HTTP_404_NOT_FOUND
    assert response.headers["content-type"].startswith("application/problem+json")

    body = response.json()
    # Error type should include the NoResultsError identifier/URI
    assert isinstance(body.get("type"), str)
    assert "NoResultsError" in body["type"]

```

To make this compile and follow your project’s conventions, you will likely need to:

1. Ensure imports at the top of `tests/routers/openml/task_list_test.py`:
   - `from httpx import AsyncClient` (or whatever async client type your `async_client` fixture uses).
   - `from starlette import status` or `from fastapi import status` (whichever you already use elsewhere).
   - `from ...routers.openml.task_list import list_tasks` (adjust module path to the actual router function).
   - `from ...exceptions import NoResultsError` (or your actual domain error module).
2. If your test client fixture is named differently (e.g. `client` instead of `async_client`) or is sync-only, update the `test_list_tasks_no_results_http` signature and call style accordingly.
3. If you already have shared “no-results” payload constants or fixtures in this test module, you may want to reuse them rather than hard-coding the example payloads in both parametrizations.
</issue_to_address>

### Comment 2
<location path="tests/routers/openml/task_list_test.py" line_range="86-94" />
<code_context>
+    ],
+    ids=["bad_limit_type", "bad_offset_type"],
+)
+async def test_list_tasks_invalid_pagination_type(
+    pagination_override: dict[str, Any], py_api: httpx.AsyncClient
+) -> None:
+    """Invalid pagination types return 422 Unprocessable Entity."""
+    response = await py_api.post(
+        "/tasks/list",
+        json={"pagination": pagination_override},
+    )
+    assert response.status_code == HTTPStatus.UNPROCESSABLE_ENTITY
+
+
</code_context>
<issue_to_address>
**suggestion (testing):** Strengthen the 422 tests by asserting on the validation error structure, not only the status code.

These tests only assert the 422 status. To better guard against regressions, also assert key fields in the error body (e.g. `detail[0]['loc']` includes `pagination.limit`/`pagination.offset` and the error type is `type_error.integer` or equivalent). This ensures the request fails for the intended validation reason, not some other 422 path introduced later.

Suggested implementation:

```python
@pytest.mark.parametrize(
    ("pagination_override", "expected_loc_suffix"),
    [
        ({"limit": "abc", "offset": 0}, ("pagination", "limit")),  # Invalid type
        ({"limit": 5, "offset": "xyz"}, ("pagination", "offset")),  # Invalid type
    ],
    ids=["bad_limit_type", "bad_offset_type"],
)

```

```python
async def test_list_tasks_invalid_pagination_type(
    pagination_override: dict[str, Any],
    expected_loc_suffix: tuple[str, str],
    py_api: httpx.AsyncClient,
) -> None:
    """Invalid pagination types return 422 Unprocessable Entity with expected validation errors."""
    response = await py_api.post(
        "/tasks/list",
        json={"pagination": pagination_override},
    )
    assert response.status_code == HTTPStatus.UNPROCESSABLE_ENTITY

    body = response.json()
    # FastAPI / Pydantic-style validation error structure
    assert "detail" in body
    assert isinstance(body["detail"], list)
    assert body["detail"], "Expected at least one validation error"

    error = body["detail"][0]
    # Ensure we are failing specifically on the pagination field we overrode
    assert "loc" in error
    assert error["loc"][-2:] == list(expected_loc_suffix)

    # Allow for common integer type error codes across Pydantic versions
    assert error.get("type") in {"type_error.integer", "int_parsing", "int_type"}

async def test_list_tasks_default(py_api: httpx.AsyncClient) -> None:

```
</issue_to_address>